home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re Dashed lines.1 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.9 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Dashed lines
  2. Sent:        6/25/96 10:58 AM
  3. Received:    6/25/96 11:13 AM
  4. From:        Henri Lamiraux, lamiraux@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >        IOW, we've gotta have this partially-baked feature because Windoze
  9. >has it, but we can't have a full-function version because the Redmond
  10. >snoozers only implemented a crippled subset of it?    The restrictions on
  11. >dashes (no curved lines, no patterned lines & only hairlines) are arbitrary
  12. >from a platform-neutral point of view.
  13. >        Sorry if I sound a bit grumpy, but if dashes are going to be a
  14. >half-baked implementation, why bother with them at all?
  15. >        This illustrates one of my major concerns with _any_
  16. >platform-independent standard, that it can become a hodge-podge of features
  17. >culled from various sources, with no internal consistency or completeness.
  18. >        Would it really be at all difficult to complete (on the Mac side) &
  19. >port (to the Windoze side) a full-featured (i.e., with an extensible set of
  20. >dash types) dash object to handle wide dashed line imaging?  Sure, a lot of
  21. >thick-lined dashes would look pretty bad, or turn into solid lines.  But a
  22. >toolset, such as ODF, probably ought not be setting policy on the basis of
  23. >"sometimes it looks bad".  Line dashes are a quite useful tool for any part
  24. >that supports pen plotter output or just wants to let the user have some
  25. >extra capabilities for drawing fancy lines.
  26. >
  27.  
  28. The feature set of ODF is like everything else subject to priority. 
  29. Dashed line were not even on my list of feature for ODF 1. The Windows 
  30. engineer working on the graphics convinced me that it was an important 
  31. feature for Windows developers and we needed to support it. Now, having a 
  32. full support for style lines was out of question for ODF 1. We had too 
  33. many more important features to support.
  34.  
  35. >        Frankly, we developers need a formal statement of policy on ODF's
  36. >imaging model.  Is ODF destined to remain a (relatively) thin graphics
  37. >model or is there a plan for growth to, e.g., a QuickDrawGX or (shudder)
  38. >Display Postscript level of platform-independent graphics capability?
  39. >Developers planning or already working on graphics-intensive parts deserve
  40. >to know how much framework support they'll be getting, and how much
  41. >platform-specific work they'll have to do to port ODF-based parts from one
  42. >platform to another.  Clearly, at this time, ODF does not have strong
  43. >support for platform-independent graphics.  But, by offering QuickDrawGX
  44. >support for the Mac, it suggests that either a) QuickDrawGX will be ported
  45. >to other platforms or b) additional platform-native graphics support
  46. >classes will be forthcoming.  Enquiring minds want to know!  <G>
  47. >
  48. >Martin
  49.  
  50. My formal statement about the ODF graphics is that it is a very thin 
  51. layer on top of the platform graphics and it will remain that way. Not 
  52. everybody needs GX or Display Postscript to write a part. The overhead of 
  53. such technology is right now too large and we cannot requiere developer 
  54. to use them to be able to use ODF. GX for me is more for 'content' than 
  55. 'user interface'. ODF Graphics is more for 'user interface' than 
  56. 'content'. I don't imagine anybody writing PageMaker or Illustrator 
  57. graphic engine using the ODF Graphics. 
  58.  
  59. The ODF graphics is very new and I agree with you needs to be expanded. 
  60. You will see some extentions in the future. Our goal is also to make it 
  61. possible for you to use something else like GX or Display postscript with 
  62. ODF. Be able to use a x-platform GX with ODF would be great but it should 
  63. be an option not a requierement.
  64.  
  65. ........................................................................
  66.  Henri Lamiraux                                      lamiraux@apple.com
  67.  Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  68. ........................................................................
  69.  
  70.